Hi. What's the status of these patches? Are these something that's going be upstream in a reasonable amount of time or a long-term external patch series?

These won't go in into the kernel as-is and may be replaced by some different implementation in the kernel sooner or later. But I keep those safe to use - aka they don't create incompatibilities with future kernels and can just be dropped from your kernel without posing any danger to your btrfs.

@Forza-tng has some explanations why those patches won't go into the kernel: https://wiki.tnonline.net/w/Btrfs/Allocator_Hints

Hi.

I noticed that type 0 data preferred has higher priority than type 3 data only. This can lead to interesting cases. For example on one server i had replaced two disks but forgot to set type 3, so they were left as type 0, while the other disks were type 3.

The result for this RAID10 was that new data were stored only on the new disks (ID 15 and 16) with a 2 stripe RAID10 instead of the expected 10 stripe RAID10.

While this was unintended, perhaps this effect could be used to tier data chunks? To test this, I created a 3 device btrfs:

1 = ssd
2 = hdd
3 = nvme

❯ grep . /sys/fs/btrfs/238f21dc-8199-4eaa-b503-ecd2983456d6/devinfo/*/type
1/type:0x00000000 # data preferred
2/type:0x00000003 # data only
3/type:0x00000002 # metadata only

❯ btrfs fi us -T .
Overall:
    Device size:		 115.00GiB
    Device allocated:		   6.03GiB
    Device unallocated:		 108.97GiB
    Device missing:		     0.00B
    Device slack:		     0.00B
    Used:			   3.00GiB
    Free (estimated):		 110.97GiB	(min: 110.97GiB)
    Free (statfs, df):		 110.97GiB
    Data ratio:			      1.00
    Metadata ratio:		      1.00
    Global reserve:		   5.50MiB	(used: 16.00KiB)
    Multiple profiles:		        no

              Data    Metadata System                              
Id Path       single  single   single   Unallocated Total     Slack
-- ---------- ------- -------- -------- ----------- --------- -----
 1 /dev/loop0 5.00GiB        -        -     5.00GiB  10.00GiB     -
 2 /dev/loop1       -        -        -   100.00GiB 100.00GiB     -
 3 /dev/loop2       -  1.00GiB 32.00MiB     3.97GiB   5.00GiB     -
-- ---------- ------- -------- -------- ----------- --------- -----
   Total      5.00GiB  1.00GiB 32.00MiB   108.97GiB 115.00GiB 0.00B
   Used       3.00GiB  3.17MiB 16.00KiB                            



❯ dd if=/dev/zero of=file6.data count=10000000

❯ btrfs fi us -T .
Overall:
    Device size:                 115.00GiB
    Device allocated:             10.03GiB
    Device unallocated:          104.97GiB
    Device missing:                  0.00B
    Device slack:                    0.00B
    Used:                          8.78GiB
    Free (estimated):            105.20GiB      (min: 105.20GiB)
    Free (statfs, df):           105.20GiB
    Data ratio:                       1.00
    Metadata ratio:                   1.00
    Global reserve:                7.67MiB      (used: 0.00B)
    Multiple profiles:                  no
              Data    Metadata System
Id Path       single  single   single   Unallocated Total     Slack
-- ---------- ------- -------- -------- ----------- --------- -----
 1 /dev/loop0 9.00GiB        -        -     1.00GiB  10.00GiB     -
 2 /dev/loop1       -        -        -   100.00GiB 100.00GiB     -
 3 /dev/loop2       -  1.00GiB 32.00MiB     3.97GiB   5.00GiB     -
-- ---------- ------- -------- -------- ----------- --------- -----
   Total      9.00GiB  1.00GiB 32.00MiB   104.97GiB 115.00GiB 0.00B
   Used       8.77GiB  9.08MiB 16.00KiB
   
   
❯ dd if=/dev/zero of=file7.data count=10000000

❯ btrfs fi us -T .
Overall:
    Device size:                 115.00GiB
    Device allocated:             15.03GiB
    Device unallocated:           99.97GiB
    Device missing:                  0.00B
    Device slack:                    0.00B
    Used:                         13.03GiB
    Free (estimated):            100.95GiB      (min: 100.95GiB)
    Free (statfs, df):           100.95GiB
    Data ratio:                       1.00
    Metadata ratio:                   1.00
    Global reserve:               12.81MiB      (used: 0.00B)
    Multiple profiles:                  no
              Data     Metadata System
Id Path       single   single   single   Unallocated Total     Slack
-- ---------- -------- -------- -------- ----------- --------- -----
 1 /dev/loop0 10.00GiB        -        -     1.00MiB  10.00GiB     -
 2 /dev/loop1  4.00GiB        -        -    96.00GiB 100.00GiB     -
 3 /dev/loop2        -  1.00GiB 32.00MiB     3.97GiB   5.00GiB     -
-- ---------- -------- -------- -------- ----------- --------- -----
   Total      14.00GiB  1.00GiB 32.00MiB    99.97GiB 115.00GiB 0.00B
   Used       13.02GiB 13.41MiB 16.00KiB

We can see that the smaller ssd fills up before it spills over onto the HDD.

OK, perhaps not very useful since we cannot easily move hot data back on the ssd. However, it could suffice as an emergency overflow to avoid ENOSPC if your workload can survive the reduced iops... :)

Yes, I think this is intentional behavior of the initial version of the patches: The type numbers are generally used as a priority sort with the *-only doing some kind of exception. My added new types follow a similar exception rule.

I'm not sure if it would be useful to put data on data-only disks first.

I think my idea of using chunk size classes for tiering may be more useful than this side-effect (what I mentioned in a report over at btrfs-todo).

But in theory, type 0 and type 3 should be treated equally as soon as the remaining unallocated space is identical... Did you reach that point? (looks like your loop dev example did exactly that if I followed correctly)

But in the end: Well, "preferred" means "preferred", doesn't it? ;-)

But in theory, type 0 and type 3 should be treated equally as soon as the remaining unallocated space is identical... Did you reach that point? (looks like your loop dev example did exactly that if I followed correctly)

The loop test did the opposite of this, where the type 0 device was filled before the type 3, even though it was smaller/had less unallocated. I had expected types 3 and 0 were treated equally, but we see that this isn't the case?

It isn't wrong or bad, just something I hadn't thought would happen.

But in the end: Well, "preferred" means "preferred", doesn't it? ;-)

Indeed 😁

Added RAID1 read balance patches, see PR description.

@Forza-tng Looking forward to some benchmark numbers if you want to do them. :-)

I think this is intentional behavior of the initial version of the patches: The type numbers are generally used as a priority sort with the *-only doing some kind of exception. My added new types follow a similar exception rule.

I made a different suggestion when those first came out. The current approach with arbitrary, use-case-based names ("data only", "data preferred", "metadata only", "metadata preferred", and "none") is going to be very confusing, especially with the implied sorting they have to do.

I suggest that the hints should be a bitmask of the kinds of allocation that would be allowed on the device. When allocation fails with the first preference, the order in which new drives are added to the free space search should be specified separately. Splitting it into two parts gives us clean options for "what is allowed" and "when is it allowed".

What is allowed

• no data, no metadata - i.e. "none", useful for removing multiple drives in parallel
• data, no metadata - we currently call this "data only"
• no data, metadata - we currently call this "metadata only"
• data, metadata - the default, identical to unpatched btrfs, called "data preferred" (IMHO that is a very confusing name for what it does)

It's much clearer what to expect when the options are expressed this way: you get metadata on a device, or you don't. There's no possibility of data spilling onto a device that you didn't ask for.

When it is allowed

To get the "preferred" options, there must be multiple allocation passes, one for each preference level. We need to specify priority for each device within each pass for each allocation type. So we expand the above to more than one bit. e.g. with two bits for each type, you have 4 levels for each:

The allocator would then run multiple passes, with each pass adding more drives from the next preference level to search for free space. This loop would stop one level before the lowest, so any device at the lowest preference level would never be used, giving us the "no data" or "no metadata" cases.

Implementation notes

• If the allocation succeeds, all further passes are skipped.
• An optimized version also skips passes when there would be no different result, e.g. if there are no devices with preference tier2 or tier3, then we don't need to run subsequent passes. This can be precomputed when the preferences are changed or when a device is added or removed.
• Currently all existing filesystems have zeros in the bytes where we want to store this field. The bit encoding should make all-zero-bits correspond to the default behavior, and the bit encoding should be sortable. That means "always" would be encoded as 00, while "never" would be encoded as 11, "tier2" is 01, "tier3" is 10.
• Userspace tools can assist with preset preference values for common use cases. e.g. mkfs.btrfs might notice a large rotating disk and a small SSD, and set up preferred metadata on SSD with overflow in both directions.
• The kernel should allow all possible combinations of options. Userspace could disallow settings which are usually undesirable (e.g. "none for all devices") if it's possible for a user who knows what they're doing to plug numeric values into the sysfs interface directly.

Use cases

An array of SSDs and HDDs split into metadata and data respectively

A pair of SSD and HDD (as you might find in a laptop) with bidirectional overflow

A pair of SSD and HDD which allows metadata to overflow to HDD, but no data to overflow to SSD

A multi-device remove with no overflow allowed to removed devices

This config prevents any new data or metadata from being allocated on the to-remove devices even if that would result in ENOSPC, e.g. if the devices are being removed because they are failing.

A multi-device remove with overflow allowed to removed devices

This config allows allocations to fall back to to-be-removed devices if other devices run out of space, making it a deliberate safety valve to prevent ENOSPC in case the user failed to estimate space correctly.

Multiple tiers

If the slowest drive is the largest one, the default allocator behavior will try to put all the metadata on the slowest drive. This config flips the allocation order in that scenario.

Future considerations

Why do we have more than one level between "always" and "never"? We only need 3 to support the proposal for "preferred", "only", and "none". 3 levels require at least 2 bits, but 2 bits have at least 4 values, so we get a second middle level for free.

We can lean into that: If the user has some complex multi-level tiered storage, or a mashup of old drives with various performance and reliability, or they're doing a complicated reshape, then that second middle level -- or a third bit to extend to a total of 6 levels + always + never -- could be useful.

If we expanded to 8 bits, we'd be able to provide drive-by-drive customized allocation order.

I can't think of a use case for this off the top of my head, but on the other hand, I didn't know about the "none" use case until I found myself in immediate need of it. Maybe someone else will run into it, or it will become part of a more general tiered storage solution.

@Zygo I like this bitfield suggestion, and it should still be easy to use for simple ordering: Just mask out the bits not used for a request, then compare the remaining. And as you already pointed out, we should rather use 3 bits for tiering: There may be much more complex scenarios of different drives (5400, 7200, 10k rpm) or maybe even network storage (iSCSI, DRBD) involved which have very different performance characteristics.

So we could have RDDDRMMM (reserved, data, metadata) in an 8-bit-field.

I'd still need to figure out why we need multiple passes or how that is different from the current implementation, and I probably need some time for it. I think your multipass idea differs in how free space is considered. We should also look into how we could properly migrate the old settings to the new ones automatically.

And instead of writing raw decimal numbers to the type field, we could probably just expose additional sysfs files like meta_tier and data_tier...

I'd still need to figure out why we need multiple passes or how that is different from the current implementation

Currently we have two semantic preference levels: one for "only", then another for "preferred". IIRC there's no explicit nested loop in the current code--we're just doing a sort by size and preference level, then we loop once through the sorted list of drives, and we cut off the search at two different points to get the preference levels. So my proposed change is to make the outer loop explicit, and run it for as many iterations as there are preference levels in use (or do it in a single loop, but order it properly so it has the same effect as a nested loop).

Making the outer loop explicit might also help clean up some weirdness that currently happens with out-of-size-order preferences and striped profile (e.g. raid5 or raid10) allocations when the device sizes don't line up with preferences the right way, e.g. you can get narrow raid5 stripes if some devices are "preferred" and some "only", because there's no way to separate metadata order from data order in the current implementation--metadata order is strictly the opposite of data order, and that's not always what we want.

The preference data type doesn't have to be bitfields, either in storage or interface. Ordinary integers (one for data, one for metadata, for each drive) will work fine. Thinking of it as generalizations layered on a single-bit yes/no preference concept may be helpful...or it may not.

Currently the patches store everything in a single integer field. One commenter the first time around suggested moving the whole thing into the filesystem tree, e.g. BTRFS_PERSISTENT_ITEM_KEY with an objectid dedicated to allocation preferences, and the offset of each key identifying the device the preferences apply to. That would allow for versioning of the parameter schema and indefinite extension of the fields (e.g. to add a migration policy).

Currently we're using the dev type field in the device superblocks because it's simpler, not because we need to bootstrap allocation directly from superblocks. btrfs has to load the trees before it can allocate anything, so the trees will be available in time to retrieve the allocation preferences.

@Zygo Thanks, that helped me get the idea...

First conclusion using latency vs round-robin:

My system uses bcache (mdraid NVMe) backed by four 7200rpm HDDs. Turns out that latency is at an advantage here. I found that the last drive in the setup is never used for reads in latency mode. Overall, latency mode gives a slightly higher throughput in game loading screens (probably due to bcache, not because I apparently use fewer disks for reading).

Investigating the behavior, I found that this last drive only claims to be 7200rpm when it is 5400rpm in reality. fio clearly shows results typical for 5400 rpm drives:

fio --rw=randread --name=IOPS-read --bs=4k --direct=1 --filename=/dev/DEV --numjobs=1 --ioengine=libaio --iodepth=1 --refill_buffers --group_reporting --runtime=60 --time_based

Tested:

Due to the latency balancer excluding the last disk from most read operations, bcache can be used better because that last disk will be avoided for bcache read caching.

So in a scenario with bcache and/or varying disk types, latency is a clear winner. Without bcache, it would still provide better latency. But in a scenario where throughput matters, you should probably be using round-robin.

I wonder if we can make a hybrid balancer which uses round-robin but weighted/grouped by latency... Because the latency balancer will clearly fail in scenarios where disk latency is only slightly off between each member: It would then prefer to read from fewer devices than it should.

Added a new read balancer latency-rr:

It tries to combine round-robin and latency into one hybrid approach by using round-robin across a set of stripes within a 120% margin of the best latency. I am currently testing this and have not yet discovered the benefits or downsides but in theory it should prefer the fastest stripes for small requests while it switches over to using all stripes for large continuous requests.

Note: The latency calculation currently uses an average of the full history of requests only - which is bad because it will cancel out changing variations over time. A better approach would be to use an EMA (exponential moving average) with an alpha of 1/8 or 1/16. This requires to sample individual bio latency and thus requires to change structs and code in other parts of btrfs. I'm not very familiar with all the internal structures yet, and the feature is still guarded by CONFIG_BTRFS_EXPERIMENTAL, making that approach more complex. OTOH, having a permanent EMA right in the bio structures of btrfs could prove useful in other areas of btrfs.

This is also why I won't try to eliminate the code duplication yet (to avoid double calculations).

Rebased to newer read policy patchset, my initial merge used an old version from Jan'25.

Important: The module parameter raid1_balancing has been renamed to read_policy.

FWIW, someone mentioned that there are some patches on the linux-btrfs mailing list: [PATCH RFC 00/10] btrfs: new performance-based chunk allocation using device roles.

I was surprised we couldn't rech around 500MiB/s (2x single device) read speeds

Yep, that doesn't work on btrfs and that's why I see no point in using raid10: It just makes head movement more pronounced and thus lowers throughput and increases latency, but btrfs doesn't read stripes in parallel. OTOH, I'm not sure if mdraid10 would be better here.

I think this needs some tuning of the round-robin size to match the read size of your sequential readers and enough queue depth, so it alternates one and the other mirror/stripe each request.

I've spent far too many hours fooling around with this exact issue on OpenZFS. With a small group of mirrors I always hit a wall somewhere around 1.6-1.7x the sum total of the individual HDD throughputs. Unlike a true/classic RAID-0 where one just reads all drives at max speed and "zippers" the data together, long seq. reads from mirrors require data hopscotch. There's unpredictable interactions with HDD internal read-ahead, how much data sits on a given cylinder, rotational latency, "blown" revolutions because you didn't quite seek to the new cylinder in time to grab the next LBA, etc.

I did discover that how the data is written and distributed across spindles matters when reading it back. If there are any knobs to influence the write allocator "pseudo stripe size" (for lack of a better term) it might be worth twisting them.

I love this kind of stuff and wish I had a btrfs mirror to join the fun. Hopefully soon...

I love this kind of stuff and wish I had a btrfs mirror to join the fun. Hopefully soon...

You're welcome :-)

Added a test patch that may fix an RCU stall logged to dmesg during heavy meta data operations (e.g. snapshot cleanup during backups).

Added a test patch that may fix an RCU stall logged to dmesg during heavy meta data operations (e.g. snapshot cleanup during backups).

@Zygo I wonder if this (abf6174) has a meaningful impact on bees... The system that was affected is one that runs bees.

Noticed an oops with these patches when doing echo 1 > devinfo/2/type while mount is still ongoing. My btrfs is big so the mount takes 20-30 minutes. Reboot and wait until mount is complete and this worked fine.
BUG: kernel NULL pointer dereference, address: 0000000000000008
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 4 UID: 0 PID: 3520 Comm: bash Not tainted 6.12.52-dirty #2
Hardware name: Penguin Computing Relion 1900/MD90-FS0-ZB-XX, BIOS R15 06/25/2018
RIP: 0010:_raw_spin_lock+0x17/0x30
Code: 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 65 ff 05 e8 c0 d8 5e 31 c0 ba 01 00 00 00 0f b1 17 75 05 c3 cc cc cc cc 89 c6 e9 97 01 00 00 0f 1f 80 00
RSP: 0018:ffffbc13a95837c8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000008
RBP: 0000000000000008 R08: ffffbc13a9583a07 R09: 0000000000000001
R10: d800000000000000 R11: 0000000000000001 R12: ffff9bee913db000
R13: 0000000000000000 R14: 00000000fffffffb R15: ffff9bee913db000
FS: 00007fd6e270f740(0000) GS:ffff9bfddfc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 00000008d9986004 CR4: 00000000003706f0
Call Trace:

__reserve_bytes+0x70/0x720 [btrfs]
? get_page_from_freelist+0x343/0x1570
btrfs_reserve_metadata_bytes+0x1d/0xd0 [btrfs]
btrfs_use_block_rsv+0x153/0x220 [btrfs]
btrfs_alloc_tree_block+0x83/0x580 [btrfs]
btrfs_force_cow_block+0x129/0x620 [btrfs]
btrfs_cow_block+0xcd/0x230 [btrfs]
btrfs_search_slot+0x566/0xd60 [btrfs]
? kmem_cache_alloc_noprof+0x106/0x2f0
btrfs_update_device+0x91/0x1d0 [btrfs]
btrfs_devinfo_type_store+0xb8/0x140 [btrfs]
kernfs_fop_write_iter+0x14c/0x200
vfs_write+0x289/0x440
ksys_write+0x6d/0xf0
trace_clock_x86_tsc+0x20/0x20
? do_wp_page+0x838/0xf90
? __do_sys_newfstat+0x68/0x70
? __pte_offset_map+0x1b/0xf0
? __handle_mm_fault+0xa6c/0x10f0
? __count_memcg_events+0x53/0xf0
? handle_mm_fault+0x1c4/0x2d0
? do_user_addr_fault+0x334/0x620
? arch_exit_to_user_mode_prepare.isra.0+0x11/0x90
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7fd6e27a1687
Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff
RSP: 002b:00007ffecb401260 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007fd6e270f740 RCX: 00007fd6e27a1687
RDX: 0000000000000002 RSI: 0000557a2c38ad20 RDI: 0000000000000001
RBP: 0000557a2c38ad20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000002
R13: 00007fd6e28fa5c0 R14: 00007fd6e28f7e80 R15: 0000000000000000

Modules linked in: rpcsec_gss_krb5 nfsv3 nfsv4 dns_resolver nfs netfs zram lz4hc_compress lz4_compress dm_crypt bonding tls ipmi_ssif intel_rapl_msr nfsd binfmt_misc auth_rpcgss nfs_acl lockd grace intel_rapl_common intel_uncore_frequency intel_uncore_frequency_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp rapl intel_cstate s>
intel_pmc_bxt ixgbe ehci_pci iTCO_vendor_support xfrm_algo gf128mul libata mpt3sas xhci_hcd ehci_hcd watchdog crypto_simd mdio_devres libphy cryptd raid_class usbcore scsi_transport_sas mdio igb scsi_mod wmi usb_common i2c_i801 lpc_ich scsi_common i2c_smbus i2c_algo_bit dca
CR2: 0000000000000008
---[ end trace 0000000000000000 ]---
RIP: 0010:_raw_spin_lock+0x17/0x30
Code: 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 65 ff 05 e8 c0 d8 5e 31 c0 ba 01 00 00 00 0f b1 17 75 05 c3 cc cc cc cc 89 c6 e9 97 01 00 00 0f 1f 80 00
RSP: 0018:ffffbc13a95837c8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000008
RBP: 0000000000000008 R08: ffffbc13a9583a07 R09: 0000000000000001
R10: d800000000000000 R11: 0000000000000001 R12: ffff9bee913db000
R13: 0000000000000000 R14: 00000000fffffffb R15: ffff9bee913db000
FS: 00007fd6e270f740(0000) GS:ffff9bfddfc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 00000008d9986004 CR4: 00000000003706f0

@eliv interesting. A workaround could be to switch your filesystem to block group tree. It would make your fs mount in seconds instead of half an hour.

https://btrfs.readthedocs.io/en/latest/btrfstune.html

A workaround could be to switch your filesystem to block group tree

@eliv @Forza-tng We should still fix this. But I'm not sure if I want to fix it for 6.12 because there's an easy work-around: Just wait, until the mount settled, only then modify the flags. It's not something you'd change on a daily basis anyways.

For next LTS (most likely 6.18) I will reduce the stripe-selection patches to add only "queue" (the 6.18 kernel brings round-robin and pid by default). According to all the benchmarks, there's absolutely no use case where latency or rr-latency has a real benefit. Then during the following year (2026) I'll want to improve the quality of the patches (for stripe selection at least, chunk type per device type is a very different thing, and there's ongoing work in the kernel currently preparing more easy integration of such patches), add more benchmarks, and then suggest to upstream.

What happens if we write to other btrfs sysfs entries, like bg_reclaim_threshold, before a mount is completed? Is it a general issue with sysfs handling, or just these patches?

What happens if we write to other btrfs sysfs entries, like bg_reclaim_threshold, before a mount is completed? Is it a general issue with sysfs handling, or just these patches?

Probably just those sysfs knobs which actually access per-device info - reading or writing may not actually make a difference here: If the info is not available yet, then there will be dragons... er, null pointers...

I think there are only few sysfs entries for btrfs which don't initialize early, or which aren't available via superblock. So this reported incident is more or less an oversight. I didn't develop those patches from scratch, they are based on other peoples work. So I should fix what I maintain. And if I identify problems in the other sysfs parts, I might submit a patch upstream. But I think a problem there is most unlikely because udev (and thus btrfsprogs) will fiddle around with some sysfs entries very early during discovery and mounting. An existing bug would most likely have already been found. ;-)

Thank you for your great patch, it helped me a lot on my NAS.
I wonder if the patch will be available for kernel 6.18? I also want to use the patch on my tablet, but it requires kernel 6.18 to properly drive the graphic card.

Thank you for your great patch, it helped me a lot on my NAS. I wonder if the patch will be available for kernel 6.18? I also want to use the patch on my tablet, but it requires kernel 6.18 to properly drive the graphic card.

Yes, it will be coming to the next LTS. But I usually do not work on it before the dot 1 or dot 2 release, although I'll try to base my patches off the dot 0 releases. Before publishing the patches, I do at least test them with my system fully booting and running the kernel but I learned the hard way, I should not do that with dot 0 releases, and sometimes even not dot 1 releases.

To give you a perspective, I'm going to work on this during the holidays. I'll probably publish the patches still in this year but if I don't, it'll be ready early January.

I hope this is okay. xpadneo folks are also waiting on the 6.18 compatibility release already... :-D

Thank you for your great patch, it helped me a lot on my NAS. I wonder if the patch will be available for kernel 6.18? I also want to use the patch on my tablet, but it requires kernel 6.18 to properly drive the graphic card.

Yes, it will be coming to the next LTS. But I usually do not work on it before the dot 1 or dot 2 release, although I'll try to base my patches off the dot 0 releases. Before publishing the patches, I do at least test them with my system fully booting and running the kernel but I learned the hard way, I should not do that with dot 0 releases, and sometimes even not dot 1 releases.

To give you a perspective, I'm going to work on this during the holidays. I'll probably publish the patches still in this year but if I don't, it'll be ready early January.

I hope this is okay. xpadneo folks are also waiting on the 6.18 compatibility release already... :-D

Early January is totally OK for me, since my NAS will continue using the 6.12 kernel until about June.

Thank you again for your great work!

Early January is totally OK for me, since my NAS will continue using the 6.12 kernel until about June.

Just out of my curiosity, and to focus my efforts better: Which features of the patch set are helping you the most?

Thank you again for your great work!

Great to hear, this is very appreciated. <3

Just out of my curiosity, and to focus my efforts better: Which features of the patch set are helping you the most?

Allocator hints (allocate metadata to SSD while keeping data in HDD) helped me a lot, it greatly enhanced my RAID performance. I also set the read policy to queue, but I did not intentionally benchmark its performance.

I'm particularly interested in the allocator hints. I'm adding small Optane devices to my systems for metadata.

Hi, sorry to bother you guys. Was [round-robin] "ungated" from behind CONFIG_BTRFS_EXPERIMENTAL=Y in 6.18?

Hi, sorry to bother you guys. Was [round-robin] "ungated" from behind CONFIG_BTRFS_EXPERIMENTAL=Y in 6.18?

No. I'm currently working on the rebase to 6.18, and I've "ungated" it so you can use it without enabling all the experimental stuff. My rebase compiles, I am currently reviewing it, and fix a non-critical bug that has been reported here. After this, I'll test drive the patches, and then publish them. You'll get a notification from this PR when I publish them, so stay tuned.

Thanks. :-)

Superseded by #40